System and computer program product for certified confidential data collaboration using blockchains

ABSTRACT

A method for providing certified confidential data collaboration between untrusted parties, including creating a changeset proposal, remotely performing a certified operation and passing the changeset proposal to the certified operation, creating a unique changeset reference validating the changeset proposal and creating a state-at-changeset structure extracting a section-state-at-changeset structure from the changeset proposal, performing a cryptographic hash of the state-at-changeset structure and the section-state-at-changeset structure, writing to a local transactional database a changeset fat twin record communicating a changeset reference notification for each fat twin record to the parties, performing a certified operation in a blockchain a certified thin twin smart contract and passing the changeset reference, the cryptographically hashed state-at-changeset structure and the cryptographically hashed section-state-at-changeset structure, validating that a previous certified operation with the same changeset reference does not exist, writing to the blockchain a new thin twin record and performing a proof-of-certified-operation on the thin twin smart contract.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of and claims priority to U.S.patent application Ser. No. 15/866,460, entitled “System and ComputerProgram Product for Certified Confidential Data Collaboration usingBlockchains,” filed in the U.S. Patent and Trademark Office on Jan. 10,2018, having at least one common inventor as the present document andhereby incorporated by reference.

BACKGROUND OF THE INVENTION Field of the Invention

The present invention is generally related to certified confidentialdata collaboration using blockchains.

Discussion of the Background

The bulk of communication, commerce and collaboration requiresconfidentiality. Confidential collaboration today is plagued by massiveinefficiencies, lack of visibility, plausible deniability, datafragmentation, inconsistent data and the like. For example, consider adoctor writing a prescription. The doctor is the source-of-truth for theprescription which is considered confidential. In the prior art, thereare two ways this is done. The doctor could write a prescription andphysically hand it to the patient. The patient might take theprescription to a pharmacy. The pharmacy might accept the prescriptionbased written on a certain type of paper or might verify theprescription by calling the doctor to confirm that the doctor hadwritten the prescription. Alternatively, the doctor might ask thepatient which pharmacy they wish to utilize. The doctor could then relaythe prescription to the pharmacy via without limitation a fax machine.The patient could then go to the pharmacy to pick up the prescriptiononce it is filled. However, the prescription could easily have beenlost, with the doctor claiming it was sent and the pharmacy claiming itwas never received. The prescription could also be an incorrect, withthe prescription containing incorrect dosage, duration or the like. Asthis example illustrates, there exists inefficiencies and specializedscheme requirements in the prior art for such a collaboration tofunction. The introduction of errors, confusion, plausible deniabilityand the like are possible.

A key element of this type of collaboration is that it is confidentialand involves more than two parties. As detailed above, simpleconfidential three-party scenarios involving confidential collaborationare fraught with numerous problems. With the introduction of additionalparties, the possibility of confusion, plausible deniability,back-and-forth and the duration necessitated by the collaboration,increases exponentially. For example, assume that the pharmacy calls aninsurance company for authorization of the prescription and that theinsurance company declines to authorize the prescription for somereason. The pharmacy might then inform the patient of thenon-authorization of the prescription by the insurance company. Thepatient may be required to call the doctor to amend the prescription insome way and the doctor might amend the prescription based on this newinformation, starting the whole process again. Importantly, in thisexample, there may be inaccuracies in the relayed information from thepharmacy to the patient and from the patient to the doctor. Theintroduction of an additional party, the insurance company, increasesthe possibility of confusion, plausible deniability, back-and-forth, andthe duration necessitated by the collaboration. The durationnecessitated by the collaboration can easily take weeks to conclude.

Blockchains are known in the prior art which may be used to collaboratein situations where the collaboration is not confidential, such as withsome simple Smart Contracts. These types of non-confidentialcollaborations are also referred to herein as transparentcollaborations. Unfortunately, blockchains known in the prior art cannotbe used as the sole mechanism for confidential communication andcollaboration without some significant compromises.

There are several impediments to using blockchains as the sole mechanismfor confidential communication and collaboration today. These includewithout limitation, scale issues relating to the message size, scaleissues relating to the transaction rate, confidentiality issues,orphaned block issues, and the like.

The size of the content of a message can easily be tens to hundreds ofmegabytes. Most blockchains known in the prior art have transactionsizes in the kilobytes, which is three orders of magnitude too small.For example, the average Ethereum transaction size as of November 2017is less than 1 KB.

Blockchains known in the prior art can scale to tens of transactions persecond, which is entirely too low a transaction rate. While there areproposals to scale blockchain transaction rates using approaches likeLightning Networks (Bitcoin) and Raiden (Ethereum), these approachesonly scale highly specific payment transaction rates. Approaches togeneral transaction scalability like Ethereum Plasma are still in theresearch stage at this time.

Blockchains known in the prior art lack confidentiality and areinherently transparent. Approaches to add confidentiality to blockchainsinclude zero-knowledge proofs, secure hardware enclaves andpartitioning-as-a-means-of-confidentiality. Zero-knowledge proofs arenot fully ready as a general-purpose solution for confidentiality. Thereare significant limitations in the types of operations they can handle.Secure hardware enclave approaches like Microsoft CoCo are still in theresearch phase. Partitioning-based confidentiality approaches likehyperledger fabric channels are limiting. For example, there is nopartition that can encompass a dynamic-chain-of-trust. By definition, adynamic-chain-of-trust forms a graph structure across potentiallymillions of users that cannot be partitioned.

There also exist orphaned block issues in the prior art. Parties cannotbe sure that that a block will not eventually be orphaned at the time ablock is added to the blockchain. For example, assume that a message issent from party₁ to party₂ and captured in block_(N). Later, party₂forwards that message to party₃ and that transaction is then captured onblock_(N+1). It is possible that block_(N) and block_(N+1) willeventually get orphaned. This effectively causes a cascading series ofrollbacks. However, the parties may have already taken off-chain actionscorresponding to the two transactions that cannot be undone. Forexample, assume that a doctor C-sends a prescription to a patient whothen C-forwards it to the pharmacy. If these two transactions end up onorphaned blocks, they can be interpreted as them being rolled back.However, the prescription may have already been filled. For blockchainslike Bitcoin this is usually overcome by waiting for some number ofconfirmations before the probability of rollback becomes negligible.This approach makes dependent transactions fraught with problems.

Referring to FIG. 1B, a chart illustrating illustrating that in theprior art, the complexity of an exemplary collaboration increases as thenumber of collaborating parties increases, is shown. Graph element 54represents the number of parties involved in the collaboration, which asshown ranges from 2 to 4 parties. Graph element 52 represents thecomplexity of the collaboration, including without limitation, thedegree potential confusion, plausible deniability, time andback-and-forth necessitated by the collaboration, and the like. Asshown, in general, as the number of parties in a confidentialcollaboration increases, the degree potential confusion, plausibledeniability, time and back-and-forth as represented by line 56 risesexponentially.

Postal certified mail is known in the prior art. The venerable postalcertified mail has long been a staple of certified commerce. However,there are several major problems associated with postal certified mail.The biggest problem is that postal certified mail knows nothing aboutthe content, but rather only its container, the envelope. Postalcertified mail is also slow and non-digital, making it very hard andinefficient to integrate into today's digital world.

Email is also known in the prior art. Email is one of the mostsuccessful general communication and collaboration tools in existenceand is used extensively by businesses. However, email has manydeficiencies with respect to collaboration. Specifically, email does notsupport an agreed-upon single version of the truth, the content can betampered with, the identity can be tampered with, timestamps can betampered with, it is repudiable, and is generally not trulyconfidential. Despite its deficiencies, there are no viable generalpurpose alternatives in the prior art for communication andcollaboration. Because email includes the above deficiencies, there is asubstantial human element involved in the interpreting, discovering,compensating and litigating, to allow certification characteristics tobe partially extracted.

File Sharing is known in the prior art and used for collaboration.However, file sharing content can be tampered with and changes arerepudiable. File Sharing is not a suitable candidate for certifiedcommunication and collaboration.

Notaries are known in the prior art. However, notaries do not enablecommunication and collaboration directly, but instead provide usefulbuilding block services such as various forms of attestation.

Biased collaboration systems are known in the prior art. In thiscontext, the term biased refers to the characteristic that one of theparties to the communication and collaboration is considered anauthoritative party. The greater the size asymmetry between the parties,the more likely it is for this model to be employed. For example, inbusiness-to-consumer (“B2C”) scenarios, the “B” side will oftenrepresent the system of truth. This means that weaker parties often haveno choice but to rely on whims of the stronger party. For example, anecommerce provider may claim that a consumer never placed an order andthe consumer has no choice to accept this or get into some sort ofcustomer service escalation with uncertain outcomes. Biasedcollaboration systems become even more problematic when the sizedisparity between parties is not so dramatic, such asbusiness-to-business (“B2B”) scenarios. This often results in a systemwhere each party has its own biased system. Now the question becomes,whose reality is definitive. In a two-party relationship, the partiescould in theory agree that a particular party's reality isauthoritative. For multi-party collaborations, even this becomesimpossible to achieve. So, these systems tend to be artificiallysegmented into pairwise relationships, making even the simplestmulti-party collaborations highly complex.

Neutral, specialized collaboration systems are known in the prior art.Examples of these systems include without limitation Uber for ridesharing, eBay for auctioning, eSignature systems for document signingand the like. However, these systems are highly specialized systems forhighly specialized use cases, require trust with a neutral party, and donot support dynamic chain-of-trust.

The present invention overcomes these and other limitations associatedwith certified confidential data collaboration.

SUMMARY OF THE INVENTION

Accordingly, one aspect of the present invention is to provide a methodfor providing certified confidential data collaboration between two ormore of a plurality of parties where an established trust relationshipis not required between the plurality of parties. The system includescreating, by a first party, a changeset proposal in the electronictransaction, communicating, by the first party, the changeset proposalto a semi-trusted governor party, creating, by the semi-trusted governorparty, a thread tracking number, performing, by the semi-trustedgovernor party, a cryptographic hash of the thread tracking number tocreate a cryptographically hashed thread tracking number, validating, bythe semi-trusted governor party, the changeset proposal and creating, bythe governor party, a state at changeset structure containing one ormore writers, performing, by the semi-trusted governor party, acryptographic hash of the changeset proposal to create acryptographically hashed changeset proposal, extracting, by thesemi-trusted governor party, a section state at changeset from thechangeset proposal, performing, by the semi-trusted governor party, acryptographic hash of the extracted section state at changeset to createa cryptographically hashed section state at changeset, writing, by thesemi-trusted governor party, to a local transactional database a fattwin record including the thread tracking number, the extracted sectionstate at changeset and the state at changeset structure, for each fattwin record, communicating, by the semi-trusted governor party, achangeset reference notification in the electronic transaction each ofthe one or more writers, writing, by the semi-trusted governor party, athin twin record in a thin twin smart contract including thecryptographically hashed thread tracking number, a changeset number, thecryptographically hashed changeset proposal, the cryptographicallyhashed state at changeset, and the cryptographically hashed sectionstate at changeset the extracted section state at changeset, thecryptographically hashed state at changeset, and communicating, by thesemi-trusted governor party, a record including the cryptographicallyhashed thread tracking number, the changeset number, the changesetproposal, the state at changeset, and the cryptographically hashedchangeset proposal to a second party.

Another aspect of the present invention is to provide a method forproviding certified confidential data collaboration between two or moreof a plurality of parties where an established trust relationship is notrequired between the plurality of parties. The method includes (i)forwarding, by a first party and mediated by a semi-trusted governorparty, a first contiguous range of changesets from a first certifiedthread, (ii) creating a second certified thread based on the firstcertified thread, (iii) writing, by the semi-trusted governor party,public cryptographically hashed information relating to first certifiedthread and public information including a cryptographically hashedthread tracking number, a changeset number and associatedcryptographically hashed content relating to second certified thread toa blockchain. The first certified thread includes confidentialinformation and public cryptographically hashed information. The secondcertified thread includes a second contiguous range of changesetsderived from the first contiguous range of changesets. The secondcertified thread contains an untampered duplicate of the firstcontiguous range of changesets which can be verified by each of therespective plurality of parties of the second certified threadregardless of whether each of the plurality of parties respectively haveaccess to the first certified thread but do have access to therespective public cryptographically hashed information relating to firstand second certified threads written to the blockchain. The forwardingof the first contiguous range of changesets from the first certifiedthread being verifiable even where the semi-trusted governor party hasbecome non-cooperative, non-available or malicious subsequent to theexecution of the forwarding of the first contiguous range of changesetsfrom the first certified thread.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete appreciation of the present invention and many of theattendant advantages thereof will be readily obtained as the samebecomes better understood by reference to the following detaileddescription when considered in conjunction with the accompanyingdrawings, wherein:

FIG. 1A is a block diagram illustrating an exemplary collaborationinvolving multiple parties;

FIG. 1B is a chart illustrating illustrating that in the prior art, thecomplexity of an exemplary collaboration increases as the number ofcollaborating parties increases;

FIGS. 1C-1E are block diagrams illustrating various exemplarycollaborations involving multiple parties;

FIGS. 1F-1G are block diagrams illustrating an exemplary system forconfidential data using blockchains in accordance with an embodiment ofthe present invention; and

FIGS. 2A-2W are flow charts illustrating a method for certifiedconfidential data collaboration in accordance with an embodiment of thepresent invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Referring now to the drawings, wherein like reference numerals designateidentical or corresponding parts throughout the several views, preferredembodiments of the present invention are described.

The present invention solves the deficiencies of the prior art byproviding without limitation confidential certified communication anddynamic chain-of-trust. Dynamic chain-of-trust allows a party, such as apatient, to forward a certified communication, such as a prescription,to another party, such as a pharmacy, in such a manner that the secondparty can trust the provenance and content of the forwardedcommunication without having direct access to the originalcommunication. A dynamic chain-of-trust is also confidential. Thepresent invention utilizes various confidential certified communicationand collaboration operations including without limitation, C-sends,C-forwards, C-update, C-drop, C-drop-updates, C-TrueCopy, andC-instantiation as defined herein. “C-send” refers to a certifiedcommunication and “C-forward” refers to a certified forward.

Table 1 below illustrates the differences between transparentcollaboration and confidential collaboration. Differences between thepresent invention and the prior art are further distinguished forconfidential collaboration.

TABLE 1 Confidential Collaboration Transparent Collaboration Prior ArtPresent Invention Supported by Yes No Yes blockchains Data SingleVersion of the Truth Fragmented and Massive decrease in ConsistencyInconsistent fragmentation and inconsistency Plausible None ExtremelyHigh None Deniability Access to All data is accessible Lack of access torelevant Significantly improved Data to make data makes transactingaccessibility Decisions hard Decentralized Yes No (Every party that isthe Massive reduction in trusted source for a piece secondarycentralization of confidential information is a point of centralization,referred to herein as “Secondary Centralization”) chain-of-trust Yes(Implicit) No Yes

To illustrate how the present invention's use of a confidential dynamicchain-of-trust massively improves certified confidential datacollaboration between multiple parties, consider a non-limiting healthindustry example. Assume that a patient that has insurance visits aphysician for a health issue. The physician orders lab results, makes adiagnosis, gives the patient a prescription and refers the patient to aspecialist. The parties involved in this non-limiting example include apatient, a physician, a specialist physician, a lab, a pharmacy, aphysician credentialing board, an insurance company, the Department ofPublic Safety (for the driver's license of the patient), and a notary.

For the first example, assume that the Department of Public SafetyC-sends a driver's license to the patient's address on file. The patientC-forwards the driver's license to a notary. The notary attests that agiven real-world identity (as proved by the Driver's license sent from adigital address) maps to a particular digital address and C-sends thisattestation back to the patient. Under this scenario, there exists adynamic chain of trust between the Department of Public Safety and thepatient, and between the patient and the notary.

Assume that the patient sets up an account with a pharmacy. The patientC-forwards the notary's attestation to the pharmacy. Now, there exists adynamic chain of trust between the notary and the patient, and betweenthe patient and the pharmacy.

Assume that the physician credentialing board C-sends the physiciancredentials to the physician. The physician could go through a similarnotary process as the patient did to associate their digital identitywith their real-world identity.

Assume that the physician creates an account with a pharmacy. Thephysician C-forwards the physician credentials to the pharmacy. Underthis scenario, there exists a dynamic chain of trust between thephysician credentialing board and the physician, and between thephysician and the pharmacy.

Assume that the physician C-forwards the notary's attestation to thepharmacy. Here, there exists a dynamic chain of trust between the notaryand the physician, and between the physician and the pharmacy.

Assume that the insurance company C-sends the insurance card to thepatient. The patient C-forwards the insurance card to the physician.Under this scenario, there exists a dynamic chain of trust between theinsurance company and the patient, and between the patient and thephysician.

Assume that the physician C-sends a lab work order to a lab. The labC-sends the lab work results to the physician referencing the lab workorder. The physician C-forwards the lab work results to the patient.Here, there exists a dynamic chain of trust between the lab and thephysician, and between the physician and the patient.

Assume that the physician C-sends a referral for a specialist physicianto the patient. The patient C-forwards the referral to the insurancecompany for authorization. There exists a dynamic chain of trust betweenthe physician and the patient, and between the patient and the insurancecompany. The insurance company C-sends the approval to the patient. Thepatient C-forwards the approval to the specialist. There exists adynamic chain of trust between the insurance company and the patient,and between the patient and the specialist. The patient C-forwards thereferral to the specialist. There exists a dynamic chain of trustbetween the physician and the patient, and between the patient and thespecialist. The patient C-forwards the proof of insurance to thespecialist. There exists a dynamic chain of trust between the insurancecompany and the patient, and between the patient and the specialist. Thepatient C-sends the lab work to the specialist. There exists a dynamicchain of trust between the lab and the physician, and between thephysician and the patient, and between the patient and the specialist.The patient C-sends an authorized request for appropriate medicalrecords from the physician. The physician C-sends the records to thepatient. The patient C-forwards the medical records to the specialist.There exists a dynamic chain of trust between the physician and thepatient, and between the patient and the specialist.

Assume that the physician C-sends the prescription to the patient. Thepatient C-forwards it to the pharmacy. Under this scenario, there existsa dynamic chain of trust between the physician and the patient, andbetween the patient and the pharmacy.

In the prior art, at every single point where a chain-of-trust isinvolved, a party must either confirm with a certifying source or trustthe relaying party (referred to herein as a static chain-of-trust). Theformer often involves multiple communications introducing substantialdelays into the process and introduces a plausible deniability for allparties which leads to substantial uncertainty, rechecking, re-verifyingand the like. Finally, each party assembles their own potentiallycontradictory facts leading to massive confusion and finger-pointing.Parties that don't like a particular outcome might utilize plausibledeniability to delay and obfuscate. The latter, also leads to asituation of plausible deniability and every party having to trust everyrelaying party. This widespread need for trust in every relaying partyis a significant impediment to commerce.

A static chain-of-trust is known in the prior art and has been used inpublic key cryptography systems like PGP. As used herein, thechain-of-trust is referred to as static because it is based on thecreation of static trust relationships. For example, if person A trustsperson B and person B trusts person C, then person A can trust person C.However, there are problems associated with static chains of trust asapplied to a confidential collaboration. The trust relationship needs tobe created up front. This severely limits the applicability of thistechnique to widespread commerce. The trust relationship is notcontextual. It is assumed to exist for all types of information. Thismakes it impractical to use except under very specialized conditions.For example, consider a doctor→patient→pharmacy chain. A pharmacy cannottrust every patient it encounters to forward a prescription from adoctor to the pharmacy without tampering. Because of this, pharmaciestypically verify the prescription by calling the doctor back. Whereprescriptions are written on a special prescription pad, the pharmacyhas to verify that this is not a forgery if they don't verify theprescription by calling the doctor back. While this might not be a highrisk for some prescriptions, it might be a high risk for otherprescriptions involving highly controlled prescriptions such as DEASchedule II Drugs, which include opiates and narcotics.

A dynamic chain-of-trust is based on not requiring up-front trust in anyof the relaying intermediaries. In blockchain terminology, the chain ismade up of trustless intermediaries, where “trustless” means that trustis not required rather than the parties being necessarily untrustworthy.As used herein, the chain-of-trust is referred to as dynamic because aconfidential trust chain is dynamically created on top of trustlessintermediaries.

According to at least one embodiment, the present invention utilizescertified communication and collaboration, which as used herein means acommunication or collaboration where certain minimal core criteria aremet in the communication and collaboration between parties, includingwithout limitation: (1) there is an agreed-upon single version of thetruth; (2) content cannot be tampered with; (3) the identity cannot betampered with; (4) timestamps cannot be tampered with; (5)communications or changes to the state are non-repudiable; (6)communications and state are confidential; (7) the system is not biasedin favor of any party; and (8) the system is general purpose.

Traditional certified mail sent via the postal system only certifiesthat a certain party sends another party something at a particular time.The biggest problem with certified mail is that the content is notcertified. According to at least one non-limiting embodiment, thepresent invention utilizes certified messaging, also referred to hereinas “C-send”. Certified messaging provides certifies the parties, thetime and the content. Certified messaging is also generally configuredas a multi-party communication, which includes the possibility of atwo-party communication. Either all of the parties receive thecommunication or none of the parties receive the communication. Such anarrangement opens up a vast number of new use-cases. For example, alegal notice sent via certified messaging certifies, the parties, thetime and the actual content of the contract and that content isnon-repudiable. This dramatically increases the value of certification.Some uses of certified messaging are sending legal notifications,business transaction communications, form submissions, statementnotifications and the like.

An example of a multi-party C-send might be a vendor sending an advanceship notice to both a buyer and a carrier as both need this information.

The present invention includes the concept of certified forwards orC-forwards. Certified forwards enable certified communications that werereceived to be forwarded to others in such a way that the finalreceiving party can (cryptographically) trust that the originalcommunication was forwarded without tampering. Importantly, they do notneed to trust the relaying party to be able to detect tampering.Certified forwards can be cryptographically trusted with respect totimestamp(s), identities and content of the certifiedcommunications/threads being forwarded, where content includes withoutlimitation comments, attachments and state. Certified forwards enable anew breed of private interactions. Certified forwards also enable adynamic transitive trust. If user1 C-sends a communication to user2 anduser2 C-forwards it to user3 and user3 C-forwards it to user4 and thelike, then user4 can trust that the entire forwarded chain is(cryptographically) trustworthy in terms of content, timing andidentity, without having to trust any of the intermediaries.

C-forwards and dynamic transitive trust are transformative in the realmof confidential transactions. For public transactions, C-forwards arenot needed and simple references (such as smart contract references)would suffice.

Blockchains provide decentralization and remove the need for trustedintermediaries. However, it is also well appreciated that the currentstate of the art does not work well for confidential transactions.Various approaches such as the Microsoft CoCo framework, Hyperledgerchannels and the like are now reaching the prototype stage to somewhataddress this issue. While these new blockchain confidentiality featureswill allow hitherto off-chain private transactions to move on-chain thiscapability is not sufficient in and of itself to enable certifiedcommunication and collaboration capabilities like confidential dynamicchain of trust.

Confidential collaboration is often comprised of a web of interrelatedtransactions. If these transactions were public then the relationshipswould be easy to model and utilize. A simple link between publictransactions would suffice. This is the situation with the publicworld-wide-web as well as public blockchains such as Bitcoin and smartcontract platforms such as Ethereum. For confidential transactions, theweb of trust of interrelated transactions is severed at the partiesthemselves. Therefore, even though the transactions themselves arestored in a decentralized manner, validating transactions requirestrusting intermediate parties. This results in a trust that depends uponthe parties which is a more acute form of trust. This is not just havingto trust a single neutral third-party, but having to trust everyrelaying party in the confidential transaction graph.

FIG. 1C is a block diagram illustrating an exemplary transaction 60involving multiple parties. Assume this a confidential transactioninvolving certified thread CT₁ 70 between party₁ 62, party₂ 66, andparty₃ 68, and certified thread CT₂ 72 between party₃ 66 and party₄ 68,where certified thread 72 has a validation dependency 71 on certifiedthread 70. Such interdependencies are fairly common in confidentialtransactions. In this example, party₃ 68, does not have access tocertified thread CT₁ 70 and therefore cannot validate certified threadCT₁ 70. Because of this, party₃ 68 cannot validate certified thread CT₂72. An example of a validation dependency is where CT₂ is asserted to bea forward of all or a subset of CT₁.

In a public transaction, by contrast, party₄ 68 would have access tocertified thread CT₁ 70 and would therefore be able to validatecertified thread CT₂ 72. Party₂ 66 may now forward certified thread CT₁70 to party₄ 68. However, in a confidential transaction, this requiresparty₄ 68 to trust party₂ 66 regarding the transaction and party₄ 68 hasno independent way of verifying the transaction. This is how a severeform of trust recentralization occurs, even if utilizing a decentralizedtechnology like a blockchain.

Certified forwards and dynamic transitive trust are the mechanism usedby the present invention to remove this trust recentralization ofconfidential transactions, which is referred to herein as “secondarydecentralization” where primary decentralization being the trustdecentralization of public transactions which is provided natively byblockchains.

FIG. 1D is a block diagram illustrating an exemplary transaction 80involving multiple parties using certified forwards (also referred toherein as “C-forwards”) enabled secondary decentralization. Assume thatparty₃ 86 C-forwards certified thread CT₁ 90 to party₄ 88 as representedby line 71. Such an arrangement facilitates validation of certifiedthread CT₂ 94, which party₄ 88 does not have access to, by means of theC-forward 92 of certified thread CT₁ 92, which party₄ 88 does haveaccess to, because a transitive trust is cryptographically ensured.Therefore, party₄ 88 no longer needs to trust party₃ 86 relative tocertified thread CT₁ as the transitive trust is cryptographicallyensured. Transitive trust allows parties to follow a dynamic chain oftrust back to an originating transaction without requiring trust in anyof the intermediate parties. In addition to secondary decentralization,transitive trust will vastly reduce the complexity and confusion of theconfidential transaction.

FIG. 1E is a block diagram illustrating an exemplary transaction 100involving multiple parties using certified forwards showing howtransitive trust can be indefinitely chained. Assume that party₃ 102C-forwards certified thread CT₂ 108 to party₅ 104 as represented by line109. Party₅ 104 then C-forwarded 110 certified thread (originally CT₂108) to party₆ 106 as represented by line 111. This could continueindefinitely. For the same reasons as previously detailed, no party nolonger need to trust another party in this chain because there exists atransitive trust between each of them in the chain.

In one non-limiting embodiment, a certified thread is only partiallyC-forwarded. For example, if a certified thread has 12 changesetsnumbered 1-12, only changesets 7-12 may be C-forwarded. The recipientwould be able to trust the content of changesets 7-12 and would alsoknow that changesets 1-6 were not forwarded. Partial C-forwarding can beeven more fine-grained.

The present invention goes beyond certified messaging to representcertified state and allows that state to be updated in a certifiedmanner. These updates are also referred to as changesets. This allowscertified threads to represent things that evolve over time, such aswithout limitation versioned entities. Not only is the creation of theentity (in the certified thread) certified, but the changes to it(changesets) are also certified. According to one non-limitingembodiment of the present invention, the primary entity is a versionedthread rather than a communication to facilitate this. A communicationis merely a special case of thread with one changeset. For example, abuyer may send a seller an order via certified messaging. However,orders are often changeable after they are created, via for instancechange orders. Rather than a C-send of a separate change order, the usercan update the initial order certified thread which creates a newversion of the order. This has the benefit of their being a certifiedlatest state of the certified thread.

According to one non-limiting embodiment of the present invention,certified threads are immutable and append-only. This means that theoriginal version of the order is version #1 and the new version of theorder is version #2. Such an arrangement provides the relevant partiesinvolved a full history of the versioned entity, such as an order, aswell as its current latest state. This eliminates the possibility ofambiguity on the current latest state. Another example would be afinance company sending statement updates via a single certified thread.The recipient will have the entire history of account statements as wellas can see the certified up-to-date account state, such as the currentbalance, at a glance. Certified threads may also be used to certifiablycollaborate on any versioned entity, including without limitationorders, wills, application forms, prescription refills, insuranceclaims, and the like. The state history is certified in that no partycan repudiate any element of the entire state history in terms ofcontent, timing, and identity.

Certified communications are a special case of a certified thread. Theyare basically a certified thread with only a single (first) changeset.C-forwards also work with certified threads with multiple changesets.Instead of just C-forwarding a communication (changeset #1), a user canC-forward an entire certified thread at a particular changeset. ThisC-forwards the entire non-repudiable history until that changeset. Anysubsequent changes are not C-forwarded. The act of adding a certifiedchangeset is also called C-updating. As used herein C-sending andC-forwarding is associated with communication and C-updating isassociated with collaboration.

The present invention may be used for certified forms. Parties can fillin forms and C-send the resulting filled-in form. Parties cancollaborate (C-update) on forms as well. Both the structure of the formand the filled-in values are certified and cannot be tampered with.Parties can create smart templates (see below) with forms or createforms on the fly. The present invention may be used with any type ofcertified form including without limitation school application forms,insurance claim forms, order forms, event registration forms, membershipforms and the like. Certified form smart templates may be madeinstantiable by everyone or only instantiable by organization users.Certified forms may be C-forwarded once completed. Forms include withoutlimitation native forms, Adobe PDF forms and the like. These forms maybe added to smart templates as detailed below. The forms are certifiedboth in terms of structure as well as in terms of value. Neither theforms structure nor the entire state history of the form can berepudiated in terms of content, timing and identity.

When a certified communication is sent to another party, that party canrespond with a non-repudiable certified read acknowledgement. Acertified read acknowledgement, also referred to herein as a“C-ReadAck”, is a special kind of changeset in which a party to thecertified thread certifies that they have read the communication (or aparticular changeset). More generally, because certified threads canhave multiple changesets, the certified read acknowledgement isgeneralized to a user confirming they have read until a certainchangeset. For example, a buyer and a seller may be negotiating acontract. This negotiation may span over multiple changesets. Forinstance, assuming there have been 15 changesets in a two-partynegotiation, if both parties acknowledge that they have read up tochangeset #15, then this acknowledgement would be reflected inchangesets #16 and #17, respectively. Certified ReadAcks arenon-repudiable and cannot be denied by any party in terms of timing,identity and the part of the thread that has been asserted to have beenread.

Certified true copies, also referred to herein as a “C-TrueCopy”,creates a certified thread which is a certified true copy of the currentstate, but not the history, of another certified thread. Certified truecopies bear a superficial resemblance certified forwards. They differ inthat the original timestamp is not considered part of the certified truecopy. Additionally, they do not propagate identity or copy the history,and certified true copies do not possess the transitive property ofC-forwards. Certified true copies are useful when a party wishes to makeproposed changes to the state of a thread and then other parties canknow in a certified manner the true certified difference between theproposed changes and the state at which the certified true copy wasmade.

A certified drop or C-drop allows the user to create a certified threadthat is not initially sent to anyone else. This essentially allows auser to later prove that the changeset existed at a point in time—apostponed proof of existence. At the time of the C-drop, no one elseknows about the existence of this dropped changeset. This is distinctfrom a public proof of existence. An example of a use-case for certifieddrops would be a C-dropping a Will. A person would normally C-forwardtheir Will to their executor. Upon that person's death, the executorcould C-forward the Will to the Will beneficiaries, probate courts,trustees and the like. C-drops and deferred C-forwarding cannot berepudiated by any party.

A user can also do drop updates, referred to herein as “C-drop-updates”,for versioned entities. In this case there is delayed proof-of-existenceof the initial drop as well as for each subsequent drop update. In theWill example, by doing C-drop-updates, the current version of the willis always evident and certified. This is particularly important on thedeath of the user.

Another use-case of C-drops would be a patent certified thread. This waya user can record the idea when they get it and establish a certifiedpriority date and related content, and later C-forward it to a patentattorney if needed. The original C-drop cannot be tampered with in termsof time, content or identity.

Certified threads can optionally be templatized into smart templates,which have some similarities with smart contracts. For instance,Ethereum smart contracts or Hyperledger smart contracts with somesignificant differences. Smart templates allow repeating patterns ofcertified threads to be codified into a reusable smart template. Smarttemplates are themselves certified threads and can be repeatedlyinstantiated to create smart template Instances. This process is calledcertified Instantiation or C-instantiation.

The differences between smart contracts and smart templates are shown intable 2 below.

TABLE 2 Smart Contract Smart Template Created By Software Developersbusiness People Code-style Imperative Declarative Command-basedstate-based, state-Change validation Deep Shallow Purposecontract-as-code Structured & Unstructured Communication andCollaboration Philosophy permissions-over-forgivenessForgiveness-over-permissions contract In Code Explicit state MarkersEnforcement Mutability Immutable Immutable, Versioned Interpreted byPrimarily code, secondarily people Primarily people, secondarily codePrivacy (of smart Public confidential contract/Template Instances)Parties On-chain On-chain and off-chain Anti-spam Ether-gasdisincentivizes spam antispam token awards (paid to (paid to miners)parties on the certified thread) Tokens Ethers CertCoins addressesEthereum addresses blockchain addresses, Ethereum addresses, Emailaddresses smart Ethereum addresses thread Tracking Number (e.g.contract/smart 123-1244-2432) template address Runs On N/A (self)Ethereum blockchain Governed by Miners the present invention governors.Each certified thread is governed by a single (trusted) governor. AppStore dApp Stores governor Template Store Instantiated into smartcontract instance certified thread instance(s)

As noted in the tale above, there many differences between smartcontracts and smart templates. For instance, smart contracts are writtenin imperative code, such as Solidity in Ethereum, ChainCode inHyperledger and the like, whereas smart templates are written in adeclarative form, which are designed using visual designers whichgenerate the declarative form.

Imperative code is an important aspect of smart contracts. Being writtenwith code means that smart contracts can encapsulate a great deal ofhighly sophisticated and specific behavior. One downside of smartcontracts is that they become exponentially harder to debug as they getmore complex. Also, by definition, they need to be written by softwaredevelopers.

A smart contract is code-as-contract and removes people from theexecution and interpretation of the contract. A smart template is atemplatized certified communication and collaboration between parties.Whether a particular smart template should be considered a contract issomething that is left to the parties to decide. A good analogy wouldbe, if an individual were to send an update to their will to theirattorney via certified mail, does that constitute a contract between theindividual and the attorney? It may or may not. Smart templates aresilent on whether the synchronized state between parties constitute alegal agreement between the parties. Smart templates are designed to becreated by business people rather than software developers and cantypically be created in a few minutes and published to template stores.

Smart contracts are based on consensus and require global visibility, orin the case of permissioned blockchains, at least community-widevisibility. This allows anyone to validate the code and achieveconsensus. However, there is global, or at least community-wide,visibility of the instance. For very simple smart contracts like sendingvirtual currency this problem may be overcome through zero knowledgeproofs. However, there is no (currently practical) possibility ofovercoming this problem for general smart contracts without severecompromises.

Smart templates are based on a confidential visibility model. Only theparties to the smart template instance have visibility to the certifiedthread. For example, if a patient, pharmacy and a doctor are the onlythree parties on a prescription instance, they will be the only threeparties who can see this certified thread instance. This visibilitymodel is considered to be absolutely critical to the vast majority ofuse-cases of the present invention. When a certified template isC-instantiated to create a certified instance of that template, therelationship between the instance and the template is non-repudiable. Inother words, an instance cannot be tampered with relative to itstemplate before it is sent.

Referring to FIG. 1F, a block diagram illustrating various entities inthe present invention, is shown. As shown, these entities includewithout limitation thread governors (132-136), parties (138-140) andvalue-added parties (“VAP”) (142-144). Each entity may have multipleroles. For example, an entity may be a governor, a party, and/or VAP.

According to one non-limiting embodiment of the present invention, atleast one governor (132-136) must exist for new C-transactions to beprocessed. Every certified thread is managed by a single governor. Agovernor is a trusted entity that provides without limitationconfidential validation of C-transactions, confidential storage ofcertified thread fat twins, and synchronization of the off-chain fattwin 154 with the on-chain thin twin 152. A certified thread, which isdiscussed in further detail below, comprises without limitation anoff-chain confidential fat twin, and an on-chain public thin twin. Atransiently semi-trusted governor is utilized for confidentialvalidations of C-transactions and therefore all C-transactions arerouted via a governor. Standard parties, place temporary trust in thegovernor. Once the governor has synchronized the fat twin with the thintwin, its job is done. All the future cryptographic proofs can be donewithout the consent, authorization or even existence of the governor.The inability to perform confidential validations is a key limitation ofblockchains known in the prior art. Blockchains known in the prior artare unable to scale to the sizes of the confidential fat twin.Confidential fat twins could easily be tens of megabytes in size,whereas the average Ethereum transaction size was less than 1 kilobyte.That is a four to five order of magnitude difference.

The standard parties are the parties transacting certified, confidentialbusiness utilizing certified threads, for example a buyer and seller onan order certified thread. The present invention includes a variety ofvalue added parties. These VAP roles are not mutually exclusive.

According to one non-limiting embodiment, the system includes an auditorVAP. The purpose of the auditor VAP is to audit the validation andcertified thread construction performed by the governor. This is anoptional safeguard against a malicious governor. Alternatively, standardparties themselves can audit any transaction, but it may be moreconvenient to rely on an auditor VAP. C-transactions are initiallyexecuted by a governor. The auditor VAP independently re-executes thetransaction asynchronously. Auditor VAPs get a changeset proposal aswell as a fat twin and optionally a parent fat twin(s) state from thegovernor. The fat twin and parent fat twin(s) are independentlyvalidated against a changeset proposal and proved against theircorresponding thin twins.

According to one non-limiting embodiment, hashed ChangesetProposals arewritten to a ChangesetProposal thin twin. This eliminates any ability ofa governor to tamper with a transaction without detection.

According to the present invention, a C-transaction may be proved orcertified using open-source code. In addition, an arbitrator VAP isprovided as a convenience for proving C-transactions. An arbitrator VAPcan be used to prove whether a particular C-transaction occurred, evenwithout any assistance from a governor and even if a governor is nolonger operating. This is because proofs can be done directly againstblockchain thin twins. The fat twins need to be provided to anarbitrator. One mechanism is to provide the fat twin in the form of afat twin zip file.

Witnesses are value added partners that participate in a certifiedthread and act as witnesses to the certified thread. They are neutralthird parties that can prove that a particular certified thread wascreated or changeset occurred. Parties can also prove that a certifiedthread was created or that a changeset happened. But this might be moreconvenient to rely on a witness. If the governor of a certified threadis an implicit witness, then utilizing a third-party witness WAP is amechanism to reduce reliance on the governor. A witness may be engagedwhere the governor is an implicit witness, the witness is added as aparty to the certified thread, and whereas certified thread is laterC-forwarded to a witness. In general, witnesses provide a subset of thecapabilities of an auditor.

The difference between a witness VAP and an arbitrator VAP is themechanism by which they obtain a fat twin. A witness VAP is a standardparty on a certified thread or has a certified thread C-forwarded tothem, whereas an arbitrator VAP obtains the fat twin throughout-of-bound mechanisms such as a fat twin zip file sent by a party thatwishes a proof. An entity may be both a witness VAP and a prover VAP.

Backup VAPs are configured to act as a backup service. They can storecertified threads (specifically the certified thread fat twin) for laterretrieval. Note that parties themselves can act as their own backupservice, but it may be more convenient to use a backup VAP. Backup VAPsmay provide different levels of guarantees in terms of storage durationand retrieval SLAs. In addition, governors may also provide implicitbackup services. However, backup VAPs can reduce reliance on a governorwhere employed.

The present invention uses the terms writer, commenter and reader. Asused herein, the term writer is used to represent a transacting party.Or said another way, a writer is a party that can make changes to thecertified thread. As used herein, the term reader is used to represent aparty that cannot make any changes to the certified thread. Finally, asused herein, the term commenter is used to represent a party that isallowed to add comments (and attachments), but is otherwise not beallowed to make any other changes. Readers and commenters will not beable to add, modify or delete sections or add other writers, readers orcommenters.

In every changeset, a sender can add zero or more writers. For example,assume that for changeset1 (CS1), party₁ sends to recipients party₂,party₃ and party₄, and designates party₂, party₃ and party₄ as writers(SAC1.writers=party₂, party₃, party₄). For changeset3, party₁ addsrecipient party₅, and designates party₅ as a writer(SAC3.writers=party₂, party₃, party₄, party₅). For changeset5, party₁adds recipients party₆ and party₇, and designates party₆ and party₇ aswriters (SAC5.writers=party₂, party₃, party₄, party₅, party₆, party₇).

In one non-limiting embodiment, rather than a backup VAP, a governorwrites the fat twin changeset, in for instance a ZIP file format, to adecentralized file system like FileCoin. The governor generates a uniquekey for each changeset referred to herein as a changeset encryption key(CEK). This CEK is retained by the governor as well as distributed toeach transacting party at that changeset in the certified thread. Thedecentralized file system acts as a backup for the transacting partiesso long as they retain their CEK. The exposure of a CEK only causes asingle changeset to be exposed. Any form of proof which requires a fattwin changeset can also be performed with a fat twin CEK.

Smart template VAPs create smart templates that are available to anyparty or entity, which helps promote standardization. For example,instead of every party defining its own purchase order, they may use thepurchase order previously defined by a particular smart template VAP.Because smart templates are a particular type of certified thread, smarttemplate creation and updates (versioning) will be routed through agovernor like any other changeset. Template stores are configured tolist the available thread templates for smart template VAPs.

Smart template specialized VAPs are VAPs that are specialized based on aparticular smart template. For example, consider a prescription smarttemplate. A prescription buddy VAP might keep a user's location andpreferences and decide which pharmacy to submit a prescription to basedon availability, pricing and the like.

A common type of specialized VAP is a deep validator VAP. governors onlydo shallow validation. In the prescription example, the smart templatemay have a certified form that represents the prescription. Basic formvalidation like presence/absence of mandatory fields, simple typevalidations, etc. Fundamentally, the governor knows nothing aboutprescriptions. A deep validator that understands prescriptions couldvalidate that a particular pharmaceutical name is valid.

Search VAPs store certified threads (specifically certified thread fattwins) and allow parties to perform searches over their certifiedthreads. Different Search VAPs may provide different degrees ofsearching.

Notary VAPs validate the true identity of a party and record that intothe certified thread. Note that true identity is considered content andhence will not be stored in the certified thread thin twin. Transactingparties can then use C-forwarding and a dynamic chain of trust to provetheir identities to any other party.

How a party proves their true identity to the notary VAP is between thenotary and themselves.

KYC or know your customer is a regulatory requirement placed on certainfinancial institutions to verify the identity of their customers. KYCVAPs can perform this verification and provide a certification which maybe c-forwarded to other institutions by the customer utilizing thedynamic trust model.

According to one non-limiting embodiment, the present invention utilizesprotocol tokens called, CertCoin tokens or CertCoins. The purpose ofCertCoin tokens is to create a balance of incentives that facilitate asmooth functioning of the present invention. One of the major problemswith current electronic communication systems such as email is theproblem of spam. The present invention uses an economic disincentive todiscourage spam by assessing a per-recipient cost (in CertCoins).Furthermore, the anti-spam fee is paid to the recipient. In effect, thetransfer amount can be considered an attention reward on the recipientside and an anti-spam fee on the sender side. Governors may be paid inCertCoins for their services. Smart template creators may be paid inCertCoins at the time of smart template instantiation. Value addedparties may be paid for their services in CertCoins.

According to one non-limiting embodiment, the present invention utilizesan underlying blockchain, which may include without limitation anEthereum blockchain. The blockchain fees may be paid by the governorperhaps in the Ethereum currency (Ethers) and collected in CertCoins.

Numerous services may be priced in terms of basic certification units orBCUs rather than directly in CertCoins, due to the price volatility oftokens such as CertCoins.

According to a non-limiting embodiment, governor(s), standard parties(senders) and VAPs must be on-chain parties. This means that they musthave an Ethereum address if the blockchain in question is the EthereumBlockchain. Standard parties who only receive communications(recipients) may be on-chain or off-chain. They only receive anti-spampayouts if they are on-chain.

According to a non-limiting embodiment, certified threads are hybridentities. They consist of two parts called “twins”. An off-chain fattwin is maintained confidentially by a governor. An on-chain thin twinis governed on a public blockchain. Such an arrangement facilitatesmaintaining private transactions (or C-transactions) directly on theblockchain.

The governor will allow parties to a certified thread to retrieve theunencrypted contents of the certified thread (the fat twin). Users mayalso interact with the certified thread via the governor fat twin.

Once a changeset has been C-sent, C-forwarded, C-updated, C-instantiatedor the like, the role of the governor is done. The proof-of-state,proof-of-existence, postponed-proof-of-existence, proof-of-true-copy,proof-of-c-forwarding, proof-of-sending, proof-of-instantiation and thelike, can be accomplished using only the thin twin smart contracts.Users requesting the proofs must supply the corresponding fat twininformation.

As previously discussed, according to one non-limiting embodiment,certified threads are hybrid entities with the fat twin managed by agovernor. Governors are responsible for managing these identities,subject to certain rules. Governors are registered using a graphicaluser interface associated with the present invention. When a governor isregistered, a governor domain name is provided which is validated by thepresent invention. The default governor at launch is without limitation“tmail21.com”. Certified thread identities are identified as follows:

-   -   <governorDomainName>://<unique-thread-tracking-nbr>.

For example, the following may be URL which include certified threadidentities:

-   -   https://tmail21.com/ttn/123-1234-1234    -   https://gov2.com/ttn/124-2314-1234

User identity is a critical to the proper functioning of the presentinvention because the dynamic-chain-of-trust concept is reliant on auser's identity. Standard user party types include without limitationindividual users, Ethereum users and organization users. Their addressformats are as follows:

TABLE 3 User type Address Format individualuserprefix$<governorDomainName> organizationuserprefix$orgname.<governorDomainName> Ethereumethereumaddress$ethereum.<governorDomainName>

Table 4 shows non-limiting examples for each user type.

TABLE 4 User type Example individual jsmith$tmail21.com organizationjsmith$org27.tmail21.com Ethereum123f681646d4a755815f9cb19e1acc8565a0c2ac$ethereum.tmail21.com

Unlike blockchain identities, identities of the present inventionidentities are not meant to be pseudonymous (except for the Ethereumuser type). This is because, in general, the present invention use-casesrequire knowledge of identity. All the present invention identities areconfidential and only known only to the parties to the thread. Theidentities and content are maintained in the fat twin. In the publicthin twin, only Ethereum identities of senders are known.

According to one non-limiting embodiment, email addresses may only beused for receiving. If a user needs to C-transact, an Ethereum user orindividual/organization user with an associated Ethereum address(assuming the Ethereum Blockchain is being used) must be utilized. If auser C-sends a communication to an email address, they can access thecertified thread through a process known as binding.

Table 5 shows the validations that occur for each type of identity.

TABLE 5 Identity Type Validation organization domain Name organizationuser domain Name and associated email address individual user associatedemail address Ethereum user owns the associated Ethereum address

Ethereum users have an on-chain identity. Individual and organizationusers have an off-chain identity and may optionally have an on-chainidentity. To maintain an on-chain identity the individual ororganization user is verifiably associated with an Ethereum addressusing their off-chain identity. Such an arrangement reduces thecomplexity of setting up an Ethereum address. An associated Ethereumaddress is not required if the individual or organization user onlyreceives communications.

According to one non-limiting embodiment, senders of changesets(C-sends, C-forwards, C-instantiate and the like) must have an on-chainidentity whereas recipients may optionally have on-chain identities.However, recipients only receive anti-spam-payouts if they have anon-chain identity. In all cases, the thin twin only exposes on-chainidentities, such as the Ethereum addresses. In the case of individualand organization users, the Ethereum address is the contemporaneousassociated Ethereum address at the time of the C-transaction.

Identities, beyond the basic identities described above, rely on dynamicchain-of-trust. For instance, with a passport identity, either thegovernment agency that issues passports or a notary would C-send anenhanced identity attestation to the user. The user can then C-forwardany enhanced identity attestation to any other user or organization thatrequires it. Such an arrangement also permits easily bootstrappingadditional identities. For example, once a user receives a passportidentity attestation, they could C-forward it and also their separatelyreceived driver's license attestation (C-Sent by the Bureau of MotorVehicles) to the bank in order to open a bank account. Once the bankreceives this they can C-send the user a proof of bank account.

Each attestation, such as a passport, driver's license, proof of bankaccount and the like, is an independent communication. The user mayC-forward these enhanced identities to other users/organizations theywish to. Thus, dynamic chain-of-trust is integral to bootstrappingenhanced levels of identities from the basic identities inherent in thesystem.

Full-service governors are governors that provide VAP services inaddition to basic governor services. TMail21 is an example of afull-service governor. In addition to basic changeset validation, italso acts as an integrated witness VAP, an integrated backup VAP, anintegrated smart template VAP and an integrated search VAP. It may alsoact as a notary VAP. These are integrated VAP services and arenot-separable from the validation service. However, TMail21.com willsupport external VAP Services.

According to a non-limiting embodiment, certified operations includewithout limitation C-send, C-update, C-forward, C-readAck,C-instantiate, C-clone, C-drop and C-dropUpdate. For each of thesecertified operations there are three distinct workflows, includingwithout limitation an execution workflow, audit workflow and acertification workflow. The execution workflow is the main execution ofthe certified operation. The audit workflow is an optional auditoperation that is done by an auditor VAP to act as a check against amalicious governor. The certification workflow is the workflow thatallows any party to the operation to prove that the particular operationdid indeed occur with time, content and parties as indicated.

The hybrid structure of fat twins validated and stored off-chain, andthin twins validated and stored on-chain, solve blockchain scale issuesrelating to size as well as blockchain confidentiality issues. However,this structure by itself does not solve other blockchain including scalerate and the problem of orphaned blocks.

In one non-limiting embodiment, aconfidential-blockchain-within-a-blockchain approach is used tomassively increase scalability. The governor groups multiple changesetsacross multiple certified threads that have been created within apredefined time interval into confidential (off-chain) blocks. Innerblocks are referred to herein as CBlocks to distinguish them from thecontaining blockchain blocks. A CBlock block contains a series of [TTN,CS, SAC] records. The governor then computes a corresponding off-chainpublic CThinBlock. A CThinBlock contains a series of [TTN, CS, SAC_(H),SSAC_(H)] records. Each CBlock and its corresponding public CThinBlockhas a sequentially increasing block number. Next, the governor computesthe CThinBlock Hash (CThinBlock_(H)) and each of the SAC_(H) andSSAC_(H) records of the CBlock are combined into a Merkel Hash(CThinBlockMerkelRoot_(H)). Finally, only the [CBlockNumber,CThinBlock_(H), CThinBlockMerkelRoot_(H)] is written to the outer (main)Blockchain. In this manner thousands of records (Certified Operations)are compressed into a single record. The governor also writes the publicCThinBlock to a decentralized file service, such as without limitationIPFS, where the CThinBlock can be retrieved based on the CThinBlock_(H).Instead of a CThinTwin smart contract, this embodiment has a CThinBlocksmart contract. This smart contract validates on-chain that theCThinBlocks are being written with sequential CBlockNumbers. Thecertification proofs in this embodiment take an additional argumentwhich is the list of public CThinBlocks which can be retrieved from thedecentralized file storage (e.g., IPFS). The prover will need tovalidate all COperations from the start of the Blockchain. In practice,this can be done by auditor VAPs rather than each prover. Auditor VAPscan then make attestations regarding the validation of the CThinBlocks.

For coin operations, scalable payment solutions which can sustain a muchhigher transaction rate like the Raiden Network on Ethereum or LightningNetwork on Bitcoin can be used. The coin operations will occursynchronously with the certified operations whereas the CBlocks arewritten at periodic intervals. For instance, the CBlocks may writtenwithout limitation every 10 minutes.

In one non-limiting embodiment, zkSnarks (zero knowledge succinctnon-interactive argument of knowledge) are used by the governor to provethat the governor ran a particular C-operation validation function,which eliminates the need for an auditor to independently verify thatthe correct validator function was run by the governor. This is done ina setup step and then in a per-C-operation step.

In the setup step, a validation function, including without limitation aC-response validation function, is used to generate a key generatorfunction (zkKeyGenerator), a prover function (zkProver) and a verifierfunction (zkVerifier). A zkSnark compiler such as ZoKrates may be usedfor this purpose. Alternatively, these functions many be manuallygenerated.

For each C-response transaction, the governor performs the C-responsevalidation function and generates a computation-proof of having run thevalidation function by also running the zkProver function which wasgenerated earlier in the setup step. The governor then writes to theC-respond operation on the blockchain thin twin which has been enhancedto accept the computation-proof as an additional argument. The enhancedthin twin smart contract may then verify the computation proof using thezkVerifier function that was generated in the setup step. Because thethin twin smart contract can verify that the governor ran the correctvalidation function, a third-party auditor VAP is no longer required tomake this determination. This has additional the advantage of doing thevalidation synchronously instead of asynchronously. The downside of thisapproach is that it is currently viable for only relatively simplevalidations and will not allow for more sophisticated validations thuslimiting the type and degree of certified operations.

In one non-limiting embodiment, a proxy re-encryption scheme is used tohide information from the governor effectively providing end-to-endencryption for the parties to the certified thread. The proxyre-encryption scheme can apply to designated sections or designatedattachments (collectively, designated content). The proxy re-encryptionscheme requires all parties to the thread to have a public/privatekeypair and make their public key known to the governor. In order toprovide this capability, the sending party generates a symmetricencryption key corresponding to the proposed changeset called aChangeset key that is not known to the governor. The sending party thenencrypts the designated content with the Changeset key. The governorcannot read this content as the governor does not know the changesetkey. Because the governor cannot read this content, the governor cannotdo any validation on this content. Next, the sender encrypts theChangeset key with their own public key to create an encrypted changesetkey. Next for each recipient as well as existing writers at thischangeset, the sender creates a re-encryption key. Finally, the sendersends the encrypted designated content, the encrypted changeset key andthe set of re-encryption keys. The governor re-encrypts the encryptedchangeset key to the public key of all or the writers at the changeset.Now all of the writers at this changeset can decrypt the re-encryptedchangeset keys to produce the changeset key. This changeset key can inturn be used to decrypt the designated content.

In one non-limiting embodiment, a re-encryption scheme is used to hideinformation from the semi-trusted governor providing end to endencryption of a designated subset of the information. In thisembodiment, on creation of a non-parented certified thread, the sendercreates a new base-thread symmetric key (BTSK) and encrypts designatedsections (DS) with this BTSK to produce encrypted designated sections(EDS). The BTSK is then further encrypted locally by the sender with thepublic keys of all recipients creating a list of encrypted-base-threadsymmetric keys (EBTSK). The EDS and the list of EBTSK are then sent tothe semi-trusted governor. The semi-trusted governor never receives theun-encrypted DS or the BTSK. A recipient can then decrypt the EBTSKusing its own private key to get BTSK. The BTSK is then used to decryptthe EDS to produce DS. Other types of certified operations can beclassified into response type certified operations (e.g., C-Respond) andparented certified thread creation certified operations (e.g.,C-Forward, C-Instantiate, C-Clone). For response type certifiedoperations, the sender determines if new parties are being added to thecertified thread. If yes, the sender re-encrypts the BTSK that with thepublic keys of the additional recipients to produce additional EBTSKallowing the additional recipients to obtain BTSK and thus decrypt EDSto produce DS. For parented certified thread creation operations, thesender encrypts the BTSK from the parent certified thread (which theyhave in their possession as they must be a party to the parent certifiedthread) using the public keys of the recipients of the child certifiedthread to produce new EBTSKs. The EDS are copied unchanged from theparent certified thread to the child certified thread. This allows thecryptographic hash comparisons to continue to work just like fornon-end-to-end-encryption sections. The new EBTSK are sent to allrecipients of the child certified thread allowing them to decrypt theEBTSK with their private keys to produce BTSK and then using BTSK todecrypt (the copied) EDS to produce DS.

In one non-limiting embodiment, the governor handles orphaned blocks byperiodically checking the blockchain to see if some changesets aremissing some duration after the changeset has been written to the thintwin. If the changeset is missing, the governor resubmits it to theblockchain. This requires the thin twin contract to be written to acceptidempotent writes from the governor. This also requires certificationproofs to be able to handle missing changesets. These missing changesetsare handled by waiting a certain amount of time which is related to thegovernor rewrite interval, and then retrying the certification proof.

In one non-limiting embodiment, there is no governor and the fat twin isalso written to the blockchain. This requires the blockchain to be ableto handle confidentiality as well as large transaction sizes. This maybe accomplished by combining a trusted-execution-environment (TEE) basedblockchain, such as Microsoft CoCo or Intel SGX Hardware, forconfidentiality along with a FileCoin like Blockchain for large sizescale. Note that both of these types of blockchains are still indevelopment.

The SAC at a particular TTN-CSN represents the state at Changeset.

SAC {  Changeset  { int changesetNum; String comment; List[Attachment]attachments; List[User] added_writers; List[SectionVer] added_sections;List[SectionVer] modified_sections;  } ThreadInfo  { String subject;String TTN; String threadType;  } SectionsSAC // SSAC  {List[SectionVer] sectionVersAtChangeset;  } WritersSAC  { List[User]writersAtChangeset;  } parentInfo // varies based on if this thread wascreated by cloning, forwarding or instantiation  {  } }

In one non-limiting embodiment, the governor generates a randomcryptographic nonce and adds it to the SAC. The governor may generate arandom cryptographic nonce by any means including without limitation bygenerating a GUID. Because SAC_(H) is on a public blockchain, it may besubject to being guessed through trial and error since it utilizes awell-known structure. By adding a cryptographic nonce to the SAC, theSAC_(H) becomes virtually impossible to guess.

In one non-limiting embodiment, the governor digitally signs the SAC byfirst computing the SAC_(H) and then applying a digital signature toSAC_(H) using an algorithm. This may be done by any known meansincluding without limitation the RSA digital signature algorithm. Thedigital signature is then added to a signed SAC structure which isSAC+digital signature. The signed SAC structure, which may be withoutlimitation represented as a ZIP file, is sent to all the writers at thegiven changeset number. This approach can be used as an alternative toplacing [TTN_(H), CSN, SAC_(H), SSAC_(H)] on the blockchain. However,this embodiment requires massive additional trust in the governorrelative to the blockchain approach. For example, with the blockchainapproach, the block timestamp is not generated by the governor and hencecannot be spoofed by the governor. The block timestamp is generated bythe blockchain miner. The block timestamp should be very near to thegovernor-asserted changeset timestamp (within a few seconds). In fact,the block timestamp could be considered the true timestamp of thechangeset. The blockchain approach ensures that there is a canonical SAC(and hence SACH and SSAC_(H)) at every [TTN, CSN] combination. Using adigital signature approach there is no canonical SAC. The governor couldgenerate multiple conflicting SACs for a given [TTN, CSN] combination atdifferent points in time. For example, at time t1 the governor couldgenerate [TTN, CSN, SAC1] and at time t2 the governor could generate[TTN, CSN, SAC2]. Alternatively, at the same time t1, the governor couldsend [TTN, CSN, SAC3] to writer1 and [TTN, CSN, SAC4] to writer2. Thefact that there is a canonical SAC at every [TTN, CSN] combination meansthat auditors, arbitrator VAPs can be assured that they are validatingor certifying the canonical SAC. The blockchain approach supportsreal-time validation audits by Auditor VAPs. However, using the digitalsignature approach the governor could send a digitally signed [TTN, CSN,SAC, CSP] to an auditor. The auditor can re-validate and digitally signthe audit, but then there is no place to put the canonical audit resultthat all parties can see. There is also the matter of how to distributethe audit results to all of the parties in such a manner that they agreeon the audit result. The governor could generate no output. Parties cancheck for absence of output by comparing the thin twin smart contractwith the auditor smart contract. Furthermore, the digital signatureapproach doesn't support fully on-chain fat twins and thin twins. Saidanother way, there is no way for it to support fully decentralized,trustless certified messaging and collaboration which is the long-termgoal. With the Blockchain approach, parties do not have to trust thegovernor that related transactions are properly generated. For example,if a party C-Forwards TTN1 [CS3-CS5] to create TTN2. With the digitalsignature approach, the parties are required to trust the governor that,for instance, TTN2.FTTN1.CS4.SAC==TTN1.CS4.SAC. With the blockchainapproach if these were different, all parties to TTN2 could immediatelydetect this. With the digital signature approach, all parties could notverify it because in general all parties do not have access to TTN1.Even for a party that does have access to TTN1, it runs into the lack ofcanonical SAC issue. If, for example, a party C-Clones TTN1 at CS4 tocreate TTN2. With the digital signature approach, the parties must trustthat the governor set TTN2.CS1.SSAC==TTN1.CS4.SSAC. With the blockchainapproach, if these were different, all parties to TTN2 could detectthis. With the blockchain approach, if these were different, all partiesto TTN2 could immediately detect this. With this digital signatureapproach, all parties could not verify it because in general all partiesdo not have access to TTN1. Even for a party that does have access toTTN1, it runs into the lack of canonical SAC issue. If, for example, aparty C-Instantiates template TTNT at R2 to create instance TTNI. Withthe digital signature approach, the parties have to trust the governorset TTNT.R2.SSAC==TTNI.CS1.SSAC. With the Blockchain approach, allparties to TTN2 could immediately detect this. With this digitalsignature approach, all parties could not verify it because in generalall parties do not have access to TTNT. Even for a party that does haveaccess to TTN1, it runs into the lack of canonical SAC issue. Finally,the digital signature approach doesn't support coin operations which arefundamental to the cryptoeconomic incentives behind certified messagingand collaboration.

In one non-limiting embodiment, a user performs a C-Send, C-Instantiate,C-Forward or C-Clone with a setting that prevents further C-Forwards.This is an artificial suppression of further C-Forwards. This is a wayto artificially terminate dynamic-chain-of-trust. This capability maysometimes be useful where users do not wish that their certified messageor changeset can be certifiably forwarded to other parties.

Referring to FIGS. 2A-2S are flow charts illustrating a method forcertified confidential data collaboration in accordance with anembodiment of the present invention. A non-limiting flowchart relatingto a C-send execution workflow 300 in accordance with an embodiment ofthe present invention is shown in FIGS. 2A-2C. At block 302, party₁creates a changeset proposal (CSP). A check for whether an audit isenabled is performed at block 304. If audit is enabled, then at blocks306 and 304, party₁ performs a cryptographic hash function on CSP togenerate CSP_(H) and write CSP_(H) to the audit smart contract (ASC).Otherwise, if an audit is not enabled, then party₁ sends the CSP to agovernor at block 310. A check for whether an audit is enabled isperformed at block 312. This step may be alternatively combined withblock 304 above. If audit is enabled, then at block 314, governorperforms a cryptographic hash function on CSP to generate CSP_(H). Thegovernor uses ASC to find CSP_(H) at block 316. At blocks 318 and 320,if the CSP_(H) is not found, then the governor terminates thetransaction [TERMINATE-EXECUTION-CSP-FAILED] with aChangeset-Proposal-Not-Verifiable.

Otherwise, if the CSP_(H) is found, then the governor creates a newthread tracking number (TTN) and performs a cryptographic hash functionon TTN to generate TTN_(H) at blocks 324 and 326. At blocks 328 and 330,the governor creates a state-at-changeset (SAC) by validating the CSP(SAC1=validate(CSP)). If the validation fails, then the governorterminates the transaction [TERMINATE-EXECUTION-VALIDATION-FAILED] atblocks 332 and 334. Otherwise, if the validation is successful, then thegovernor performs a cryptographic hash function on SAC to generateSAC_(H) at block 336. At block 338, the governor computes the sectionSAC (SSAC=SAC.SectionsState). The governor performs a cryptographic hashfunction on SSAC to generate SSAC_(H) at block 340. At block 342, thegovernor writes a fat twin record comprising [TTN, CS1, SAC] A governorwill typically write the tat twin record to a transactional databasethat is owned and controlled by the governor. For each writer in SAC,the governor writes ChangesetRef notification comprising [TTN, CS1,writer] in the same transaction, at block 344. A governor can maintaininboxes for each user. These inboxes are different from email inboxes inthat they contain only references to a changeset rather than a copy ofthe actual message or changeset. A governor can write [TTN, CS1, SAC] tothe fat twin table(s) and a ChangesetRef [TTN, CS1, writer] to the inboxtable in the same transaction. If the user has for instance a mobileapp, then the governor could additionally send a push notification tothe user's cell phone.

At blocks 346 and 348, if on-chain-payment then the payment amountparty₁ is computed. If party₁ has an insufficient balance, then[TERMINATE-EXECUTION-INSUFFICIENT-BALANCE] occurs at blocks 350 and 352.At block 354, the governor creates a thin twin on the thin twin smartcontract (TTSC) comprising [TTN_(H), CS1, SACH, SSACH, CSP_(H)]. Thethin twin smart contract is written into the Ethereum blockchain. Anon-chain-payment determination is made at block 356. At blocks 358, 360and 362, if on-chain-payment is true and party₂ is on-chain, then thepayment amount to transfer from party₁ to governor, auditor and party₂is computed, and the thin twin smart contract calls the coin smartcontract (CSC) to transfer tokens from party₁ to the governor, auditorand party₂. Otherwise, at blocks 364 and 366, if on-chain-payment istrue and party₂ is not on-chain, then the payment amount to transferfrom party₁ to governor and auditor is computed, and the thin twin smartcontract calls the coin smart contract (CSC) to transfer tokens fromparty₁ to the governor and auditor. The governor sends [#TTN, CS1, SAC,CSP] to party₁ and party₂. After the transaction is committed to thegovernor database, the governor sends [#TTN, CS1, SAC, CSP] to party₁and party₂. Because a changeset is immutable, it does not need to besent in the same transaction. There may be many reason for sending thisinformation. For instance, if party₁ or party₂ need to later do acertification proof, then this information would need to be presented toan arbitrator or to the respective other party. Typically, the partieswould just store the information for potential later use. Theinformation may be sent in several forms, including without limitation aZIP file form. Finally, [TERMINATE-C-SEND-SUCCEEDED] occurs.

A non-limiting flowchart relating to an C-send audit workflow 370 inaccordance with an embodiment of the present invention is shown in FIGS.2D-2E. At block 372, auditor VAP receives [CSPGov, TTN_(H), CS1] fromthe governor. A cryptographic hash function is performed on CSPgov togenerate CSPgov_(H) at block 374. At block 376, the auditor VAP checksif the CSP_(H) associated with [TTN_(H), CS1] on the thin twin smartcontract is the same as CSPgov_(H). If false, then at blocks 378 and380, the auditor VAP writes AUDIT-FAILED-UNVERIFIABLE-CSP on [#TTN, CS1]record in the thin twin smart contract and terminates with[TERMINATE-AUDIT-FAILED-UNVERIFIABLE-CSP]. The auditor performs avalidation (SAC=validate(CSPgov)) at block 382. At blocks 384, 386 and388, if validation fails, the the auditor VAP writesAUDIT-FAILED-INVALID-OPERATION on [#TTN, CS1] record in the thin twinsmart contract, and terminates with[TERMINATE-AUDIT-FAILED-INVALID-OPERATION]. At block 390, the auditorVAP computes the section state-of-changeset (SSAC=SAC.SectionsState).The auditor VAP performs a cryptographic hash function on SAC togenerate SAC_(H) at block 392. At block 394, the auditor VAP performs acryptographic hash function on SSAC to generate SSAC_(H). The auditorVAP checks SAC_(H) and SSAC_(H) associated with the [TTN_(H), CS1]record in the thin twin smart contract is the same as the ones hecomputed at block 396. At blocks 398, 400 and 402, if false, then theauditor VAP writes AUDIT-FAILED-INVALID-SAC-HASH and terminates with[TERMINATE-AUDIT-FAILED-INVALID-SAC-HASH]. The auditor VAP writesAUDIT-PASSED to the [TTN_(H), CS1] record in the thin twin smartcontract at block 404 and terminates with TERMINATE-AUDIT-PASSED.

A non-limiting flowchart relating to a certification proof of a C-sendworkflow 410 in accordance with an embodiment of the present inventionis shown in FIGS. 2F-2G. At block 412, party₁ sends [TTN_(H), CS1, SAC,B] to Arbitrator VAP. Arbitrator VAP computes section SAC(SSAC=SAC.SectionsState) at block 414. At blocks 416 and 418, arbitratorVAP performs a cryptographic hash function on SAC to generate SAC_(H)and performs a cryptographic hash function on SSAC to generate SSAC_(H).Arbitrator VAP compares SAC_(H) and SSAC_(H) computed with correspondingversions in thin twin smart contract at [TTN_(H), CS1] at block 420. Atblocks 422, 424 and 426, if not the same, then the arbitrator VAPnotifies party₁ and B that Certification has failed and terminates with[TERMINATE-CERTIFICATION-FAILED]. Arbitrator VAP checks if thin twinsmart contract at [TTN_(H), CS1] has an audit record at block 428. Atblocks 430, 432 and 434, if yes, and audit record is in AUDIT-FAILEDstate then arbitrator VAP notifies party₁ and party₂ that certificationhas succeeded but there is an underlying AUDIT-FAIL, and terminates with[TERMINATE-CERTIFICATION-SUCCEEDED-WITH-AUDIT-FAIL-WARNING]. ArbitratorVAP notifies party₁ and party₂ that certification has succeeded and that[TTN_(H), CS1, SAC] is non-repudiable and binding and terminates with[TERMINATE-C-SEND-CERTIFICATION-SUCCEEDED] at block 436.

A non-limiting flowchart relating to a C-forward execution workflow 440in accordance with an embodiment of the present invention is shown inFIG. 2H. At block 442, party₂ creates CSP to C-forward TTN2.CS1-TTN2.CS5and TTN1.CS4-TTN1.CS7. party₂ sends the CSP to governor at block 444. Atblock 446, the governor validates the CSP (SAC=validate(CSP, TTN2,TTN1)). In general, this is a recursive validation. Validation can failfor a variety of reasons, including without limitation the CSP hasinvalid structure [VALIDATION-FAILED-INVALID-CSP], party₂ does not haveaccess to the TTN [VALIDATION-FAILED-NO-PERMISSION], the Changesetsspecified do not exist [VALIDATION-FAILED-CHANGESETS-DO-NOT-EXIST], orthe Changeset is not a tail truncation[VALIDATION-FAILED-NOT-A-TAIL-TRUNCATION]. At block 452, the governorgenerates a new TTN (TTN3). The governor performs a cryptographic hashfunction on TTN3 to generate TTN3_(H) at block 454. At block 456, thegovernor computes section SAC (SSAC=SAC.SectionsState). The governorperforms a cryptographic hash function on SAC to generate SAC_(H) andperforms a cryptographic hash function on SSAC to generate SSAC_(H), atblocks 458 and 460. At block 462, the governor writes fat twin [TTN,CS1, SAC]. For each writer in SAC, the governor writes ChangesetRef[TTN, CS1, writer] in same transaction at block 464. At block 466, thegovernor creates a thin twin using the thin twin smart contract[TTN3_(H), CS1, SAC_(H), SSAC_(H)]. The governor sends [TTN_(H), CS1,SAC] to party₂ and party₃, and terminates with[TERMINATE-C-FORWARD-SUCCEEDED]. The governor can send to to party₂ andparty₃ in several forms. One form is a ZIP file form.

A non-limiting flowchart relating to a certification proof of aC-forward workflow 470 in accordance with an embodiment of the presentinvention is shown in FIGS. 2I-2K. At block 472, party₂ sends [TTN_(H)3,CS1, SAC, SSAC, C] to arbitrator VAP. Arbitrator VAP performs acryptographic hash function on SAC to generate SAC_(H) and performs acryptographic hash function on SSAC to generate SSAC_(H). at blocks 476and 478. At block 480, arbitrator VAP compares these computed SAC_(H)and SSAC_(H) with the values on the thin twin at [TTN_(H)3, CS1]. Ifthese values do not match, then arbitrator VAP notifies party₂ andparty₃ that certification has failed and terminates with[TERMINATE-CERTIFICATION-FAILED], at blocks 482, 484 and 486. At block488, arbitrator VAP computes ForwardedThread[ ]=SAC.ForwardedThreads.Arbitrator VAP recursively verifies the forwarded chain. Blocks 490-526show the steps for each ForwardedTTN (FTTN) in ForwardedThread[ ]. Atblock 492, arbitrator VAP performs a cryptographic hash function onFTTNto generate FTTN_(H). Arbitrator VAP finds FTT_(H) in the thin twinsmart contract at block 494. At blocks 496, 498 and 500, if FTT_(H)cannot be found, then arbitrator VAP notifies party₂ and C thatCertification has failed, and terminates with[TERMINATE-CERTIFICATION-FAILED-CANNOT-FIND-FORWARDED-THREAD]. Blocks502-526 show the steps for each CSN in ForwardedThread[FTT]. At block504, arbitrator VAP finds [FTTN_(H), CSN] in thin twin smart contract.If Arbitrator VAP cannot find [FTTN_(H), CSN], then the arbitrator VAPnotifies party₂ and C that certification has failed and terminates with[TERMINATE-CERTIFICATION-FAILED-CANNOT-FIND-CHANGESET-IN-FORWARDED-THREAD],at blocks 506, 508 and 510. At block 512, arbitrator VAP computesFSAC=SAC.ForwardedSACs(FTT, CSN). Arbitrator VAP computesFSSAC=FSAC.SectionsState at block 514. At blocks 516 and 518, arbitratorVAP performs a cryptographic hash function on FSAC to generate FSAC_(H)and performs a cryptographic hash function on FSSAC to generateFSSAC_(H). A determination of whether FSAC_(H) or FSSAC_(H) do not match[FTT_(H), CSN, SAC_(H)] or [FTT_(H), CSN, SSAC_(H)] on the thin twin, atblock 520. At blocks 522, 524 and 526, if they don't, arbitrator VAPnotifies party₂ and party₃ that certification has failed and terminateswith [TERMINATE-CERTIFICATION-FAILED-FORWARDED-THREAD-SACS-DONT-MATCH].At block 528, arbitrator VAP notifies party₂ and party₃ thatcertification has succeeded and that [TTN3_(H), CS1, SAC, SSAC] whichincludes [TTN2_(H), CS1-CS5] and [TTN1_(H), CS4-CS7] is non-repudiableand binding, and terminates with[TERMINATE-C-FORWARD-CERTIFICATION-SUCCEEDED].

A non-limiting flowchart relating to a C-update/C-respond executionworkflow 530 in accordance with an embodiment of the present inventionis shown in FIG. 2L. At block 532, party₁ creates CSP to C-respond toTTN. party₁ sends CSP to governor at block 534. At block 536, thegovernor validates CSP (SAC=validate(CSP, TTN)). Validation can fail fora variety of reasons, including without limitation if CSP has invalidstructure [VALIDATION-FAILED-INVALID-CSP] or if party₁ does not haveaccess to TTN [VALIDATION-FAILED-NO-PERMISSIONS], at blocks 538 and 540.At block 542, the governor computes section SAC(SSAC=SAC.SectionsState). The governor performs a cryptographic hashfunction on SAC to generate SAC_(H) and performs a cryptographic hashfunction on SSAC to generate SSAC_(H) at blocks 544 and 546. At block548, the governor generates new CSN (CSX). The governor appendsChangeset to fat twin [TTN, CSX, SAC] at block 550. At block 552, foreach writer in SAC, the governor writes ChangesetRef [TTN, CSX, writer]in same transaction. The governor appends to thin twin via the thin twinsmart contract [TTN_(H), CSX, SAC_(H), SSAC_(H)] at block 554. At block556, the governor sends [TTN_(H), CSX, SAC] to party₁ and all otherwriters at CSX and terminates with [TERMINATE-C-RESPOND-SUCCEEDED]. Thiscan be sent in several forms. One form is a ZIP file form.

A non-limiting flowchart relating to a certification proof of aC-update/C-respond workflow 560 in accordance with an embodiment of thepresent invention is shown in FIG. 2M. At block 562, party₁ sends[TTN_(H), CSX, SAC, SSAC, B] to arbitrator VAP. Arbitrator VAP performsa cryptographic hash function on SAC to generate SAC_(H) and performs acryptographic hash function on SSAC to generate SSAC_(H) at blocks 566and 568. At block 570, arbitrator VAP compares these computed SAC_(H)and SSAC_(H) with the values on the thin twin at [TTN_(H), CSX]. Ifthese values do not match, then the arbitrator VAP notifies party₁ andparty₂ that Certification has failed and terminates with[TERMINATE-CERTIFICATION-FAILED], at blocks 572, 574 and 576. At block578, arbitrator VAP notifies party₁ and party₂ that certification hassucceeded and that [TTN_(H), CSX, SAC, SSAC] response is non-repudiableand binding, and terminates with[TERMINATE-C-RESPOND-CERTIFICATION-SUCCEEDED].

A non-limiting flowchart relating to a C-instantiate execution workflow580 in accordance with an embodiment of the present invention is shownin FIG. 2N. At block 582, party₁ creates CSP to C-instantiate templateTTNT at ReleaseX. party₁ sends CSP to governor at block 584. At block586 and governor validates CSP constructs SAC(SAC=instantiation-validate(CSP, TTNT, ReleaseX)). If valid, then theC-instantiate terminates at blocks 588 and 590. Validation can fail fora variety of reasons, including without limitation CSP has invalidstructure [VALIDATION-FAILED-INVALID-CSP], TTNT does not exist[VALIDATION-FAILED-TEMPLATE-DOES-NOT-EXIST], TTNT/ReleaseX does notexist [VALIDATION-FAILED-TEMPLATE-RELEASE-DOES-NOT-EXIST], or party₁does not have permissions to instantiate template TTNT[VALIDATION-FAILED-NO-INSTANTIATION-PERMISSION]. At block 592, thegovernor extracts the SectionsState from the SAC (SSAC). The governorperforms a cryptographic hash function on SAC to generate SAC_(H) andperforms a cryptographic hash function on SSAC to generate SSAC_(H). atblocks 594 and 596. At block 598, the governor generates a new threadtracking number TTNI. The governor generates a new fat twin of typeInstance [TTNI, CS1, SAC] at block 602. At block 604, for each writer inSAC, the governor writes ChangesetRef notification [TTNI, CS1, writer]in same transaction. The governor creates a thin twin of type Instancevia the thin twin smart contract [TTNI_(H), CS1, SAC_(H), SSAC_(H)] atblock 606. At block 608, the governor sends [TTNI_(H), CS1, SAC] toparty₁ and all other writers in SAC. This can be sent in several forms.One form is a ZIP file form. The C-instantiate execution endssuccessfully with [TERMINATE-C-INSTANTIATE-SUCCEEDED] at block 610.

A non-limiting flowchart relating to a certification proof ofC-instantiate workflow 620 in accordance with an embodiment of thepresent invention is shown in FIGS. 20-2P. At block 622, party₁ sends[TTNI_(H), CS1, SAC, SSAC, B] to Arbitrator VAP. Arbitrator VAP performsa cryptographic hash function on SAC to generate SAC_(H) and performs acryptographic hash function on SSAC to generate SSAC_(H) at blocks 626and 686. At block 630, the arbitrator VAP compares these computedSAC_(H) and SSAC_(H) with the corresponding values on the thin twin at[TTNI_(H), CS1]. If these values do not match, then the Arbitrator VAPnotifies party₁ and party₂ that certification has failed with[TERMINATE-CERTIFICATION-FAILED] at blocks 632, 634 and 636. At block638, the arbitrator VAP extracts TTNT from SAC. The arbitrator VAPcompares thin twin [TTNI_(H), CS1].SSAC_(H) with thin twin [TTNI_(H),CS1].SSACH at block 640. At blocks 642, 644 and 646, if these values donot match, then the arbitrator VAP notifies party₁ and party₂ thatcertification has failed with[TERMINATE-CERTIFICATION-FAILED-INSTANCE-SSAC-DIFFERENT-FROM-TEMPLATE-SSAC].At block 648, the arbitrator VAP notifies party₁ and party₂ thatcertification has succeeded and that the C-instantiation represented by[TTNI_(H), CS1, SAC, SSAC] is non-repudiable and binding. Thecertification successfully ends with[TERMINATE-C-INSTANTIATE-CERTIFICATION-SUCCEEDED] at block 650.

A non-limiting flowchart relating to a C-clone/C-TrueCopy executionworkflow 660 in accordance with an embodiment of the present inventionis shown in FIG. 2Q. At block 662, party₁ creates CSP to C-clonecertified thread TTN1 at CSX. party₁ sends CSP to governor at block 664.At block 666, the governor validates CSP and constructs SAC(SAC=instantiation-validate(CSP, TTN, CSX)). If CSP is not valid, thenthe C-clone/C-TrueCopy fails validation at blocks 668 and 670.Validation can fail for a variety of reasons, including withoutlimitation, the CSP has invalid structure[VALIDATION-FAILED-INVALID-CSP], TTN does not exist[VALIDATION-FAILED-THREAD-DOES-NOT-EXIST], TTNT/CSX does not exist[VALIDATION-FAILED-CSX-DOES-NOT-EXIST], or party₁ does not have accessto TTN1 [VALIDATION-FAILED-NO-PERMISSION]. At block 672, the governorextracts (SectionsState) SSAC from SAC. The governor performs acryptographic hash function on SAC to generate SAC_(H) and performs acryptographic hash function on SSAC to generate SSAC_(H) at blocks 674and 676. At block 678, the governor generates a new thread trackingnumber TTNclone. The governor generates a new fat twin of type Instance[TTNclone, CS1, SAC] at block 682. At block 684, for each writer in SAC,the governor writes ChangesetRef notification [TTNclone, CS1, writer] insame transaction. The governor creates a thin twin via the thin twinsmart contract [TTNclone_(H), CS1, SAC_(H), SSAC_(H)] at block 686. Atblock 688, the governor sends [TTNclone_(H), CS1, SAC] to party₁ and allother writers in SAC. This can be sent in several forms. One form is aZIP file form. The C-clone/C-TrueCopy execution successfully ends with[TERMINATE-C-CLONE-SUCCEEDED] at block 690.

A non-limiting flowchart relating to a certification proof ofC-clone/C-TrueCopy workflow 700 in accordance with an embodiment of thepresent invention is shown in FIGS. 2R-2S. At block 702, party₁ sends[#TTNclone, CS1, SAC, SSAC, party₂] to arbitrator VAP. Arbitrator VAPperforms a cryptographic hash function on SAC to generate SAC_(H) andperforms a cryptographic hash function on SSAC to generate SSAC_(H) atblocks 704 and 706. At block 708, the arbitrator VAP compares thesecomputed SAC_(H) and SSAC_(H) with the corresponding values on the thintwin at [TTNclone_(H), CS1]. If these values do not match, then thearbitrator VAP notifies party₁ and party₂ that certification has failedand terminates with [TERMINATE-CERTIFICATION-FAILED] at blocks 712 and714. At block 716, arbitrator VAP extracts TTN1 from SAC. Arbitrator VAPcompares thin twin [TTN1_(H), CS1].SSAC_(H) with thin twin[TTNclone_(H), CS1].SSACH at block 718. If these values do not match,then the arbitrator VAP notifies party₁ and party₂ that certificationhas failed and terminates with[TERMINATE-CERTIFICATION-FAILED-CLONE-SSAC-DIFFERENT-FROM-CLONED-SSAC]atblocks 720, 722 and 724. At block 726, the arbitrator VAP notifiesparty₁ and party₂ that certification has succeeded and that the C-clonerepresented by [TTNclone_(H), CS1, SAC, SSAC] is non-repudiable andbinding. The certification proof of C-clone/C-TrueCopy successfully endswith [TERMINATE-C-CLONE-CERTIFICATION-SUCCEEDED] at block 728.

A non-limiting flowchart relating to a C-response-validation workflow730 in accordance with an embodiment of the present invention is shownin FIGS. 2T-2W. At blocks 732 and 734, if user does not exist, then thevalidation failed. If TTN does not exist or the user does not haveaccess to TTN, then the validation failed, at blocks 736 and 738. Atblocks 740 and 742, the current_csn is set to TTN.latest.csn and adetermination is performed for if (NOT validate_comment(CSP.comment)),then the validation failed. For each attachment in CSP.attachments, adetermination is made if (NOT validate_attachment(attachment)) and ifnot valid then the validation failed, at blocks 744, 746 and 748. Atblocks 750, 752 and 756, for each writer in CSP.writers the writerstructure is validated and the user exist validation occurs. If (NOTvalidate_writer_structure(writer)), then the validation failed, atblocks 752 and 754. At blocks 756 and 758, if (NOT user_exists(writer)),then the validation failed. For each deleted section inCSP.deleted_sections, then if section.section_num does not exist in thisTTN, then the validation failed, at blocks 760, 762 and 764. At blocks766, 768 and 770, for each added section in CSP.added_sections, theTYPE=section.type and if(NOT added_section_validate(TYPE, section)),then the validation failed. For each modified section inCSP.modified_sections, a section number validation, a section validationand a modified section validation occurs, at blocks 772, 774, and 782.At blocks 774 and 776, if section.section_num does not exist in thisTTN, then the validation failed. If section does not have a previousversion, then the validation failed, at blocks 778 and 780. At blocks782 and 784, TYPE=section.type. and if (NOTmodified_section_validate(TYPE, section, previous_version)), then thevalidation failed. If (CSP.expected_latest_cnum provided ANDCSP.expected_latest_cnum !=current_csn), then the validation failed, atblocks 786 and 788. The C-response-validation successfully ends at block790.

While the present invention has been described with reference to one ormore particular embodiments, those skilled in the art will recognizethat many changes may be made thereto without departing from the spiritand scope of the present invention. Each of these embodiments andobvious variations thereof is contemplated as falling within the spiritand scope of the claimed invention, which is set forth in the followingclaims.

This invention may be embodied in many different forms and should not beconstrued as limited to the embodiments set forth herein. Rather, theseembodiments are provided so that this disclosure will be thorough andcomplete, and will fully convey the scope of the invention to thoseskilled in the art. Like numbers refer to like elements throughout. Asused herein, the term “and/or” includes any and all combinations of oneor more of the associated listed items.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the invention. Asused herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof.

Unless otherwise defined, all terms (including technical and scientificterms) used herein have the same meaning as commonly understood by oneof ordinary skill in the art to which this invention belongs. It will befurther understood that terms, such as those defined in commonly useddictionaries, should be interpreted as having a meaning that isconsistent with their meaning in the context of the relevant art andwill not be interpreted in an idealized or overly formal sense unlessexpressly so defined herein.

As will be appreciated by one of skill in the art, the invention may beembodied as a method, device, or computer program product. Accordingly,the present invention may take the form of an entirely hardwareembodiment or an embodiment combining software and hardware aspects allgenerally referred to herein as a “circuit” or “module.”

The present invention thus includes a computer program product which maybe hosted on a computer-usable storage medium having computer-usableprogram code embodied in the medium and includes instructions whichperform the processes set forth in the present specification. Thestorage medium can include, but is not limited to, any type of diskincluding floppy disks, optical disks, CD-ROMs, magneto-optical disks,ROMs, RAMs, EPROMs, EEPROMs, flash memory, magnetic or optical cards, orany type of media suitable for storing electronic instructions.

Computer program code for carrying out operations of the presentinvention may be written in an object-oriented programming language suchas Java®, Smalltalk, C# or C++. However, the computer program code forcarrying out operations of the present invention may also be written inconventional procedural programming languages, such as the “C”programming language or in a visually oriented programming environment,such as VisualBasic.

The program code may execute entirely on the user's computer, partly onthe user's computer, as a stand-alone software package, partly on theuser's computer and partly on a remote computer or entirely on theremote computer. In the latter scenario, the remote computer may beconnected to the user's computer through a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Obviously, many other modifications and variations of the presentinvention are possible in light of the above teachings. The specificembodiments discussed herein are merely illustrative, and are not meantto limit the scope of the present invention in any manner. It istherefore to be understood that within the scope of the disclosedconcept, the invention may be practiced otherwise then as specificallydescribed.

1. A method for providing certified confidential data collaborationcommunication between two or more of a plurality of parties where anestablished trust relationship is not required between the plurality ofparties, the method comprising: creating, by a first party, a changesetproposal, the changeset proposal comprising a comment and a list ofparties; remotely performing, by the first party, a certified operationon a computer associated with a semi-trusted governor party and passingthe changeset proposal to the certified operation; creating, by thesemi-trusted governor party, a first globally unique changeset referencein a certified thread; validating, by the semi-trusted governor party,the changeset proposal and creating, by the semi-trusted governor party,a state-at-changeset structure comprising the validated changesetproposal and a timestamp; performing, by the semi-trusted governorparty, a cryptographic hash of the state-at-changeset structure;writing, by the semi-trusted governor party, a changeset fat twin recordcomprising the state-at-changeset structure; communicating, by thesemi-trusted governor party, a changeset reference notification for eachfat twin record to each of the one or more parties; performing, by thesemi-trusted governor party, the certified operation in a blockchain acertified thin twin smart contract and passing the changeset reference,the cryptographically hashed state-at-changeset structure; and writingby the thin twin smart contract to the blockchain a new thin twin recordcontaining the changeset reference and the cryptographically hashedstate-at-changeset structure.
 2. The method of claim 1, wherein thechangeset proposal further comprises a list of versioned and typed datasections.
 3. The method of claim 2, wherein the method furthercomprises: extracting, by the semi-trusted governor party, asection-state-at-changeset structure from the changeset proposal,wherein the section-state-at-changeset structure is a subset of a totalstate of the list of versioned and typed data sections; performing, bythe semi-trusted governor party, a cryptographic hash of thesection-state-at-changeset structure; writing, by the semi-trustedgovernor party, to a local transactional database a changeset fat twinrecord comprising the changeset reference and the associatedstate-at-changeset structure and section-state-at-changeset structure;wherein performing, by the semi-trusted governor party, the certifiedoperation in a blockchain a certified thin twin smart contract furtherincludes passing the cryptographically hashed section-state-at-changesetstructure; and wherein the new thin twin record, written by the thintwin smart contract to the blockchain, further contains thecryptographically hashed section-state-at-changeset structure.
 4. Themethod of claim 3, wherein the changeset proposal further comprises alist of attachments.
 5. The method of claim 1, wherein whether thecertified operation expressed by the changeset reference occurred may beproved by each of the list of parties by: performing aproof-of-certified-operation on the thin twin smart contract and passingthe changeset reference, the cryptographically hashed state-at-changesetstructure and cryptographically hashed state-at-changeset structure,wherein the proof may be determined even where the semi-trusted governorparty is unresponsive after performance of the certified operation, andwherein the blockchain thin twin record constrains the semi-trustedgovernor party that becomes untrustworthy from re-issuing the certifiedoperation with tampered timestamps, tampered identities, tamperedattachments or tampered comment to one or more of the list of parties,the blockchain thin twin record constraining the ability of thesemi-trusted governor party that is no longer trustworthy fromre-issuing the certified operation with at least one selected from thegroup consisting of tampered timestamps, tampered identities, tamperedattachments and tampered comment.
 6. The method of claim 5, wherein thefirst globally unique changeset reference comprises a first globallyunique thread tracking number and a related sequential changeset number.7. A method for providing certified confidential data collaborationbetween two or more of a plurality of parties where an established trustrelationship is not required between the plurality of parties, themethod comprising: creating, by a first party, a changeset proposal, thechangeset proposal comprising a comment, a list of parties, and a listof versioned, modifiable sections; remotely performing, by the firstparty, a certified operation on a computer associated with adecentralized governor running in a trusted execution enclave andpassing the changeset proposal to the decentralized governor, whereinthe decentralized governor cannot execute the certified operationincorrectly without detection and is not required to be trusted toaccurately execute the certified operation, wherein the trusted enclaveenvironments performs the certified operation without revealing anyconfidential information to a third party other than the two or more ofthe plurality of parties to the collaboration and specifically notrevealing any confidential information to even if the third party is incommunication with the decentralized governor, and without requiring thedecentralized governor to be trusted; creating, by the decentralizedgovernor, a first globally unique changeset reference in a certifiedthread; validating, by decentralized governor, the changeset proposaland creating, by the decentralized governor, a state-at-changesetstructure comprising the validated changeset proposal and a timestamp;extracting, by the decentralized governor, a section-state-at-changesetstructure from the changeset proposal, wherein thesection-state-at-changeset structure is a subset of a total state of thelist of modifiable sections; performing, by the decentralized governor,a cryptographic hash of the state-at-changeset structure; performing, bythe decentralized governor, a cryptographic hash of thesection-state-at-changeset structure; writing, by the decentralizedgovernor, a changeset fat twin record within the trusted executionenclave comprising the changeset reference and the associatedstate-at-changeset structure and section-state-at-changeset structure.communicating, by the decentralized governor, a changeset referencenotification for each fat twin record to each of the one or moreparties; allowing, by the decentralized governor, access to the fat twinrecord to each of the or more parties to the collaboration, but notallowing access to the third party even if the third party is incommunication with the decentralized governor; performing, by thedecentralized governor, the certified operation on a blockchaincertified thin twin smart contract and passing the changeset reference,the cryptographically hashed state-at-changeset structure and thecryptographically hashed section-state-at-changeset structure; andwriting by the thin twin smart contract to the blockchain a new thintwin record containing the changeset reference, the cryptographicallyhashed state-at-changeset structure and the cryptographically hashedsection-state-at-changeset structure.
 8. The method of claim 7, whereinthe certified operation expressed by the changeset reference, thesection-state-at-changeset structure including the timestamp andidentities of the parties, and the state-at-changeset structureincluding the timestamp and a list of identities for each of the list ofparties, occurred may be proved by each of the list of parties by:cryptographically hashing the state-at-changeset structure and thesection-state-at-changeset structure associated with the certifiedoperation; and performing a proof-of-certified-operation on the thintwin smart contract and passing the changeset reference, thecryptographically hashed state-at-changeset structure andcryptographically hashed state-at-changeset structure, wherein the proofmay be determined even where the decentralized governor is unresponsiveafter performance of the certified operation, and wherein the blockchainthin twin record constrains the decentralized governor that becomesuntrustworthy from re-issuing the certified operation with tamperedtimestamps, tampered identities, tampered attachments, tampered sectionsor tampered comment to one or more of the list of parties, theblockchain thin twin record constraining the ability of thedecentralized governor that is no longer trustworthy from re-issuing thecertified operation with at least one selected from the group consistingof tampered timestamps, tampered identities, tampered attachments,tampered sections and tampered comment.
 9. The method of claim 8,wherein the method further comprises validating, by the certified thintwin smart contract, that there does not exist a previous certifiedoperation with the same changeset reference.
 10. A method for providingcertified confidential data collaboration between two or more of aplurality of parties where an established trust relationship is notrequired between the plurality of parties, wherein a separate one of aplurality of governors is individually associated with each of the twoor more of the plurality of parties to the collaboration respectively,the method comprising: creating, by a first party, a changeset proposal,the changeset proposal comprising a comment and a list of parties;performing, by the first party, a certified operation on a computerassociated with the first party, wherein the governor is associated withthe first party has a changeset proposal to the certified operation;creating, by the governor associated with the first party, a firstglobally unique changeset reference in a certified thread; creating, bythe governor associated with the first party, a state-at-changesetstructure comprising the changeset proposal and a timestamp performing,by the governor associated with the first party, a cryptographic hash ofthe a changeset fat twin record comprising the changeset reference andthe associated state-at-changeset structure; generating, by the governorassociated with the first party, a changeset encryption key; encrypting,by the governor associated with the first party, the state-at-changesetstructure using the changeset encryption key to produce anencrypted-state-at-changeset structure; writing, by the governorassociated with the first party, to a decentralized file system on aremote computer the encrypted fat twin record comprising theencrypted-state-at-changeset structure to ensure that a third partyother than the two or more of the plurality of parties to thecollaboration and their respective party associated governors does nothave access to the fat twin record and to ensure end-to-end encryptionand confidentiality, wherein one end of an end-to-end encryption isdefined as the combination of a party and its party associated governor;communicating, by the governor associated with the first party, achangeset reference notification for each encrypted fat twin record onthe decentralized file system to each of the one or more parties;performing, by the governor associated with the first party, thecertified operation on a blockchain certified thin twin smart contractand passing the changeset reference, the cryptographically hashedstate-at-changeset structure; writing by the thin twin smart contract tothe blockchain a new thin twin record containing the changesetreference, the cryptographically hashed state-at-changeset structure andthe cryptographically hashed section-state-at-changeset structure; anddistributing by the governor associated with the first party thechangeset encryption key to all the other parties on the collaborationat the changeset.
 11. The method of claim 10, wherein the governorassociated with the first party, encrypts the changeset encryption key,with the respective public key of each of the other collaboratingparties, and wherein the method further comprises: writing the list ofencrypted changeset encrypted keys to the thin twin smart contract,retrieving, by a second party, the encrypted changeset encryption keyfrom the thin twin smart contract; decrypting, by the second party, theencrypted changeset encryption key using their private key to obtain thechangeset encryption key; and decrypting, by the second party, theencrypted fat twin record from the decentralized file system using thechangeset encryption key to obtain the fat twin record.
 12. The methodof claim 10, wherein the changeset proposal further comprises a list ofmodifiable sections and a list of attachments.
 13. The method of claim11, wherein the certified operation expressed by the changesetreference, the section-state-at-changeset structure including thetimestamp and identities of the parties, and the state-at-changesetstructure including the timestamp and a list of identities for each ofthe list of parties, occurred may be proved by each of the list ofparties by cryptographically hashing the state-at-changeset structureand the section-state-at-changeset structure associated with thecertified operation; and performing a proof-of-certified-operation onthe thin twin smart contract and passing the changeset reference, thecryptographically hashed state-at-changeset structure andcryptographically hashed state-at-changeset structure, wherein theblockchain thin twin record constrains each of the party associatedgovernors that becomes untrustworthy from re-issuing the certifiedoperation with tampered timestamps, tampered identities, tamperedattachments, tampered sections or tampered comment to one or more of thelist of parties, the blockchain thin twin record constraining theability of each of the party associated governors that is no longertrustworthy from re-issuing the certified operation with at least oneselected from the group consisting of tampered timestamps, tamperedidentities, tampered attachments, tampered sections and tamperedcomment.
 14. The method of claim 13, wherein each of the partyassociated governors may play the role of an auditor VAP and validatethe correspondence between the encrypted fat twin and theblockchain-based thin twin and write validation attestations to theblockchain associated with the changeset reference.